IN THE UNITE 



In re PATENT APPLICATION ol 
Inventor(s): PUUSKARI et al 




PATENT AND TRADEMARK OFFICE 



Appln. No.: 


09 


891,509 


Series 




1 s Serial No. 


Code 







Filed: June 27, 2001 

Title: TRANSPORTING QoS MAPPING INFORMATION 



Group Art Unit: 2182 
Examiner: Not Yet Assigned 



P 281472 


2990408USA/K/KP 


M# 


Client Ref 



■u Date: September 13, 2001 

<) 

SUBMISSION OF PRIORITY 
DOCUMENT IN ACCORDANCE 
WITH THE REQUIREMENTS OF RULE 55 



Hon. Asst Commissioner of Patents 
Washington, D.C. 20231 

Sir: 

Please accept the enclosed certified copy(ies) of the respective foreign application(s) listed below for which 
benefit under 35 U.S.C. 1 19/365 has been previously claimed in the subject application and if not is hereby claimed. 



Application No. 



Country of Origin 



Filed 



990253 
990009 
991177 



FINLAND 
FINLAND 
FINLAND 



February 9, 1999 
January 5, 1999 
May 24, 1999 



Respectfully submitted, 

Pillsbury Winthrop LLP 
Intellectual Property Group 



1 600 Tysons Boulevard By Atty: Chr^tine H. McCarthy Reg. No. 41844 




McLean, VA 22102 Sig: UH/ff " I W Fax: (703)905-2500 

Tel: (703) 905-2000 / Tel: (703) 905-2143 

Atty/Sec: CHM/JRH 



3021S057_1.DOC 



PAT-122 4/00 



.PATENTTI- JA REKISTERIHALLITUS 

NATIONAL BOARD OF PATENTS AND REGISTRATION 



Helsinki 13.6.2001 




JKI KEUSTODISTUS 
ORITY DOCUMENT 



Haki j a 
Applicant 



Nokia Telecommunications Oy 
Helsinki 




Tekemispaiva 
Filing date 



Patenttihakemus nro 
Patent application no 



Etuoikeushak . no 
Priority from appl . 



FI 990009 



09.02.1999 



990253 



Tekemispaiva 
Filing date 



05.01.1999 



Kansainvalinen luokka 



H04L 



International class 

Keksinnon nimitys 
Title of invention 

"QoS mapping in a telecommunications network" 
(QoS-kartoitus tietoliikenneverkossa) 

Haki j an nimi on hakemusdiaariin 29.02.2000 tehdyn nimenmuutoksen 
jalkeen Nokia Networks Oy. 

The, application has according to an entry made in the register 
of patent applications on 2 9.02.2000 with the name changed into 
> Nokia Networks Oy. 

'Tat en todistetaan, etta oheiset asiakirjat ovat tarkkoja jaljennoksia 
^ patent ti- ja rekisterihallitukselle alkuaan annetuista selityksesta, 
patentt ivaatimuksista, tiivistelmasta ja piirustuksista . 

f This is to certify that the annexed documents are true copies of the 
description, claims, abstract and drawings originally filed with the 
Finnish Patent Office. 




Marketta Tehikoski 
Apulaistarkastaja 



Maksu 
Fee 



300,- mk 
300,- FIM 



Osoite: Arkadiankatu 6 A Puhelin: 09 6939 500 

P.O.Box 1160 Telephone: + 358 9 6939 500 

FIN-00101 Helsinki, FINLAND 



Telefax: 09 6939 5328 

Telefax: + 358 9 6939 5328 




QoS mapping in a telecommunications network 



Background of the invention 

The invention relates to methods and equipment for controlling 
Quality of Service (QoS) in mobile communications systems having a packet 
5 data transmission capability. More specifically, the invention relates to sending 
data packets on the basis of QoS mapping information and transportation of 
the QoS mapping information between various nodes in such a mobile 
communications system. 

For the GPRS phase 2 and UMTS systems a more comprehensive 
10 QoS support is required. For this purpose, QoS-related information must be 
maintained at the network boundary elements, e.g., at the MS and GGSN. 

Methods and equipment for maintaining such QoS-related 
information and some possible mappings between external QoS mechanisms 
and enhanced GPRS QoS mechanisms have been described in references 1 
15 and 2 which are co-assigned earlier patent applications. However, these 
references are not published at the priority date of the present application, and 
the relevant subject-matter of them is substantially repeated here. 

Currently it is not possible to transform information needed to 
perform QoS mapping and translation functions between the external network 
20 QoS mechanisms and mobile network specific QoS mechanisms. This means 
that only very static QoS translation can be carried out by the mobile network 
boundary nodes. For providing different QoS values for different applications 
(such as real-time or non-real-time multimedia, file transmission, background 
e-mail transfer etc.) means for maintaining consistent information at the mobile 
25 station (MS) and GGSN nodes are needed. 

No solutions for this problem are known for GPRS/UMTS networks. 
In the Internet there are mechanisms available that can be used to transport 
QoS or flow specific information. However, this information is interpreted by 
every node along the end-to-end transmission path and not only by the 
30 endpoints (the MS and the GGSN). 

Disclosure of the invention 

An object of the invention is to provide a mechanism for enabling 
more dynamic QoS provisioning for individual applications. This object is 
achieved with a method and equipment which are characterized by what is 
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disclosed in the attached independent claims. Preferred embodiments of the 
invention are disclosed in the attached dependent claims. 

The invention is based on a vision that QoS mapping information 
must be transferred between the GPRS/UMTS network boundaries In other 
words, The .nvention provides a mechanism for mapping multiple downlink IP 
flows (IPflowl, ... iPflown) with different QoS needs to GPRS (or UMTS ) 
flows. The latter flows are defined by PDP contexts (PDP1 ... PDPm) or QoS 
profiles (QoSpl ... QoSm) within one profile fulfilling the needs. The basic idea 
is that for at least some data flows (e.g. real-time applications), the mapping 
bemg performed in the boundary node (i.e. GGSN) is based on a filter which is 
configurable (by selection or modification) from a user/terminal. Such a filter 
can be implemented as a set of predetermined parameters and/or conditions 
which are used to identify packets or data flows. A filter for a mobile station 
should comprise at least the IP address of the mobile station in question The 
15 MS's IP address is known from the PDP context record, and it does not have 
to be transmitted in the filter specification between the MS and the GGSN 
Additionally, the filter may comprise any data which can be used for identifying 
data packets requiring a certain QoS, and which should therefore be 
multiplexed onto certain PDP contexts, such as Source Address, RSVP Flow 
20 Idenffier, Port Number (e.g. the TCP or UDP port number used), Upper layer 
protocol (e.g. UDP, RTP, etc.), Type of Service (IPv4), Connection Type (IPv6) 
and/or Traffic Class field (IPv6). The filter may also comprise the IP Address 
Space for giving a higher QoS for packets coming from a corporate network 
(i.e. intranet) than for packets from the common Internet. 
25 The filter according to the invention is used to define the 

characteristics of the IP flows that are to be mapped to the GPRS flow in 
question. The terminal may control the filter identifying the filter parameters in 
an information element which can be included e.g. in a PDP context activation 
or a PDP context modification message. The filter can be also be 
30 defined/redefined in connection with QoS profile activation or modification. 

According to a preferred embodiment of the invention, a default 
QoS class is defined. Data flows which do not conform to any defined filters 
are mapped to this default QoS class. 

The problem solved by the invention is relevant in GPRS phase 2 
35 and its future evolution, such as UMTS. 



According to one embodiment, QoS information for the 
profile/context is included in the QoS Profile information element as in GPRS 
phase 1. The mapping and filtering information may be transferred in the 
protocol configuration options information element, vendor-specific options, or 
5 in a new information element introduced and devoted to this purpose. This 
information may include source and/or destination IP addresses, TCP and 
UDP port numbers used, upper layer protocol information, possibly Secure 
Parameters Index (if IPSEC is used), differentiated services parameters, and 
RSVP filters and flow specifications, or some other identifier or parameters in 

10 the packets. 

For each PDP Address a different quality of service (QoS) profile 
may be requested. For example, some PDP addresses may be associated 
with E-mail that can tolerate lengthy response times. Other applications cannot 
tolerate delay and demand a very high level of throughput, interactive 

15 applications being one example. These different requirements are reflected in 
the QoS profile. If a QoS requirement is beyond the capabilities of a PLMN, 
the PLMN negotiates the QoS profile as close as possible to the requested 
QoS profile. The MS either accepts the negotiated QoS profile, or deactivates 
the PDP context. 

20 An advantage of the invention is that the network elements (such as 

the SGSN nodes and the Base Station Subsystem) of a packet radio network 
do not have to interpret all QoS mechanisms of the external networks (IP, X.25 
etc.) Instead, the mapping can be configured at the mobile station end and this 
configuration will be transported to the other boundary node (i.e. the GGSN) of 

25 the packet radio network. Thus the entire packet radio network does not have 
to be updated to support all new QoS mechanisms. 

The mechanism according to the invention is very generic. In other 
words, it is applicable in a wide variety of situations and configurations. It 
allows flexible access, configuration and usage of the filter information in the 

30 GGSN database. Use of the filter according to the invention is entirely case 
and operator specific. The MS subscriber is provided with means for indicating 
to the gateway node at the mobile/fixed network boundary how the different 
applications, connections, flows, or other attributes should be treated and 
which QoS should be used within the GPRS/UMTS network to transport the 

35 associated packets. Preferably, the GGSN should also maintain applica- 
tion/QoS/flow specific information. 



Yet another advantage is that the flow/QoS specification transferred 
in the QoS profile establishment procedure or in the PDP context 
establishment can be very flexible. It could include source and destination IP 
addresses, TCP and UDP port numbers used, upper layer protocol 
information, possibly Secure Parameters Index in the case IPSEC is used, 
differentiated services parameters, and RSVP filters and flow specifications, all 
of which are used to identify external applications, usages and flows that 
should be mapped to particular internal QoS classes or contexts. 

Alternatively, information could be configured in a more static 
manner, in which case no dynamic change of attributes is possible. In this 
case the operator configures static conditions and translation of external QoS 
to internal QoS, for example, based on the used TCP/UDP port numbers. Yet 
another option is not to provide any QoS mapping functions and end-to-end 
QoS at all. 

Brief description of the drawings 

The invention will be described in more detail by means of preferred 
embodiments with reference to the appended drawing wherein: 

Fig. 1 shows the architecture of a known GPRS/UMTS network; 
Fig. 2 shows a known GPRS/UMTS transmission plane; 
Fig. 3 shows the interworking between different network elements; 
Fig. 4 shows a GGSN comprising the filter according to the 

invention; 

Fig. 5 shows the use of the filter according to the invention; and 
Figs. 6 and 7 show transporting the filter information in a context 
activation or modification procedure, respectively. 

Detailed description of the invention 

As shown in Figs. 1 and 2, the present invention can be applied to 
any mobile communications system having a packet data transmission 
capability. 

The term 'packet data protocol' (PDP) or 'PDP context' as used 
herein should be understood to generally refer to any state in a mobile station 
and in at least one network element or functionality, which state provides a 
data packet transmission path or a tunnel with a specific set of parameters 
through the mobile communications network. The term 'node' as used herein 
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should be understood to generally refer to any network element or functionality 
which handles the data packets transferred through the PDP channel. 

The invention can be especially preferably used for providing a 
general packet radio service GPRS in the pan-European digital mobile 
5 communication system GSM or in corresponding mobile communication 
systems, such as DCS1800 (also known as GSM1800) and PCS (Personal 
Communication System). In the following, the preferred embodiments of the 
invention will be described by means of a GPRS packet radio network formed 
by the GPRS service and the GSM system without limiting the invention to this 

10 particular packet radio system. 

The invention is equally applicable in so-called third generation 
mobile networks, such as UMTS. In this case, the GSM radio interface will be 
replaced with an UMTS radio interface, as shown in Fig. 2. 

Fig. 3 illustrates the interworking between different network 

15 elements. After these modifications, a parameter-level mapping between 
differentiated services and RSVP in the Internet and in GPRS may be 
provided as follows, for example: 

Priority information in the Internet is mapped to service precedence 
in GPRS. An indication concerning real-time vs. non-real-time requirements in 

20 the Internet is mapped to delay class and/or reliability information in GPRS: at 
least two delay types are needed, but mapping of traffic types more precisely 
to several delay classes is also possible. 

Reliability information may be used to indicate the reliability 
requirements of each application in the form of one of at least two reliability 

25 classes. If reliable transmission (retransmissions, checksums and/or TCP) is 
needed, the profile associated with the data packets indicates reliability class 
1. If reliable delivery over the radio interface is needed, but UDP in the GPRS 
backbone is sufficient, the profile associated with the data packets indicates 
reliability class 2. Depending on the requirements, the profile associated with 

30 the data packets may alternatively indicate reliability class 3, 4 or 5. Reliability 
classes 4 and 5 will be used for real-time traffic. 

A further feature of the present invention may be a mapping of the 
QoS parameters used in the mobile-communication network to those used in a 
user application in the mobile packet data terminal or those used in the 
35 external communication system, and vice versa. The MS, knowing the 
requirements of the applications, determines the corresponding QoS profile 



values, establishes a new PDP context for these packets and indicates to the 
GGSN how to recognise packets belonging to this context. In the following, 
two examples of the mapping will be given. 

Example 1 (given as an example of how the MS can decide which 
GPRS parameter values it chooses for the context). 

Simple Integrated Media Access (SIMA) is a new simple approach 
presented as an Internet-Draft by K. Kilkki, Nokia Research Center, June 
1997. Internet-Drafts are working documents of the Internet Engineering Task 
Force (IETF), its areas, and working groups. SIMA is used as an example of 
an Internet QoS scheme because it is capable of providing a uniform service 
concept for different needs from file transfer applications using TCP/IP 
protocol without loose delay and packet loss requirements to real-time 
applications with very strict quality and availability requirements. According to 
the SIMA concept, each user shall define only two issues before the 
connection setup: a nominal bit rate (NBR) and the selection between real- 
time and non-real-time service classes. The NBR may have eight values 0 to 
7. Mapping of parameters from SIMA to GPRS and vice versa may be as 
follows, for example: 

Real-time/non-real-time bit: if this bit indicates real-time require- 
ments, it is mapped to GPRS delay class 1 , otherwise it is mapped to delay 
class 4. However, delay class 3 may be used for non-real-time services in 
case there is a special way to indicate best-effort traffic, e.g. this bit shall not 
always be present, or a more precise definition is used to differentiate real- 
time, non-real-time, and best-effort traffic. A lower Reliability Class value may 
be assigned to real-time traffic than to non-real-time traffic in GPRS. 
Generally, Reliability classes 1, 2, and 3 are usually used for non-real-time 
traffic and classes 3, 4, and 5 for real-time traffic in GPRS. For non-real-time 
traffic, the higher the NBR is, the lower Reliability Class value is suitable for 
transmission. 



NBR values 


GPRS service precedence value 


6 and 7 


1 


3, 4, and 5 


2 


0, 1, and 2 


3 
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Different names, such as priority or Nominal Bit Rate and traffic 
type, may also be chosen for the parameters. The QoS Profile may include all 
the existing parameters (service precedence, reliability class, delay class, 
mean bit rate and peak bit rate). Alternatively, it could only include some of the 
5 parameters, such as the mean and peak bit rates. QoS Profile could also 
include a maximum burst size parameters to ease buffer allocation procedure. 

QoS scheduling in GPRS network elements (e.g. in an SGSN and a 
GGSN) is based on the delay class. This may require at least two buffers : one 
for real-time packets (this buffer should be much smaller!) and another one for 
10 non-real-time packets. Real-time traffic should always be sent before non-real- 
time traffic. Service precedence defines the order in which packets can be 
dropped in case of network congestion. 

Example 2 (describes how to choose QoS values and establish a 
special profile to support a given differentiated services code point, for 
15 providing proper QoS profile values and a differentiated services code point 
value as filter information for configuring the filter). 

Mapping a Type of Service (ToS) octet in the headers of IP PDUs to 
GPRS attributes. The ToS octet in an IP header is not widely used at the 
moment. Its original purpose was to include traffic type information and to 
20 specify what kind of service is required from the packet delivery. Because the 
ToS octet is not in common use nowadays, it is possible to redefine the bits in 
that octet for the purposes of the present invention. A definition of the ToS 
octet is given in RFC 791. Bits 0 to 2 of ToS give the preference, bits 3 to 5 
give the ToS required by the packet (e.g. delay, throughput, and reliability 
25 levels requested), and bits 6 to 7 are reserved for future use. RFC 1349 
extends the ToS field by one bit (taken from the "reserved for future" bits). 
Thus, 4 bits can be used to indicate a ToS. 

Mapping between the precedence bits (0 to 2 in ToS) and GPRS 
service precedence may be as follows: 

30 



bit values (0 to 2) 


service precedence value 


111 and 110 


001 (highest priority) 


101, 100, and 011 


010 (normal priority) 


010, 001, and 000 


01 1 (lowest priority) 
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There are three different ways to perform the mapping between the 
traffic type information (i.e. ToS field in the ToS octet) and the GPRS delay 
class: 

If only the bit 3 in the ToS field is used to indicate the delay 
5 requirements in IP header: value 0 of bit 2 is mapped to GPRS delay class 1 
or 2 and value 1 of the bit 2 is mapped to GPRS delay class 4 (best effort). 

If the whole ToS field in ToS is used for indicating delay 
requirements, i.e. 4 bits (bits 3-6) are available for that purpose, one possible 
mapping could be: bit value 1000 is mapped to GPRS delay class 1 (i.e. to bit 
10 value 000), bit value 0100 to GPRS delay class 2 (i.e. to value 001), ToS 
values 0010 and 0001 to GPRS delay class 3 (i.e. to value 010), and the ToS 
value 0000 to GPRS delay class 4 (i.e. to value 01 1). 

Another way of mapping the IP's ToS bits to GPRS delay classes 
would be: 11x to delay class 1, 10x to delay class 2, 01 x to delay class 3, and 
15 OOx to delay class 4. In this case, x means that there might be one or more 
additional bits used for ToS, but they do not have any impact on the process of 
selecting the GPRS delay class. If more delay classes will be defined for 
GPRS later, the mapping could take into account also those additional bits. 

Currently there is also one bit in the IP ToS field specifying the 
20 desired reliability level. If this bit is still available in the future, e.g. if the first 
choice above is chosen, this bit could carry reliability information and could be 
mapped to GPRS reliability class in the following way: a value 0 in bit 5 inside 
the ToS octet is mapped to the reliability class 000 (subscribed reliability class) 
and a value 1 is mapped to the reliability class 001 (defining the most reliable 
25 service). The use of that bit may however be too vague because the GPRS 
defines many other reliability levels as well and this cannot be expressed 
using only one bit. 

According to a preferred embodiment of the invention, a default 
QoS class is defined, and data flows not conforming to any of the mapping 
30 criteria defined by the filter(s) are mapped to the default QoS class. 

The mapping described above in Example 2 may be applied in a 
rather similar way in IPv6. The name of the appropriate field is then Traffic 
Class instead of ToS. 

Fig. 3 illustrates the operation of a GPRS mobile station and GPRS 
35 network elements, as well as integration with external network QoS concepts. 
The MS or the software in the terminal equipment TE (e.g. in a laptop 
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computer) provides mapping of external network QoS requirements to GPRS 
QoS mechanisms. The TE could for example provide QoS management 
functions through an Application Programming Interface (API). The 
application-level software may insert into the data packets, e.g. inside the IP 
5 header itself, the QoS information or a profile tag, or it can indicate the correct 
flow which the packet belongs to using some other suitable means. It can also 
use the RSVP to convey the necessary information via appropriate mapping 
layers to lower layers. The software of the MS may, alternatively, decide the 
QoS profile based e.g. on the used source and destination IP addresses, or on 

10 the source and destination port numbers, or on some other information 
configured to the MS. 

For Mobile Originated (MO) data, the MS schedules data packets 
based on the QoS information received from the application or from the GPRS 
protocol suite in the Terminal Equipment. The MS schedules the incoming MO 

15 packets according to their delay class. In the SNDC layer, the MS selects the 
appropriate LLC SAP (Service Access Point)as indicated by the SGSN during 
PDP context activation or modification: 

Fig. 4 illustrates a GGSN comprising the filter according to the 
invention. The GGSN receives MS-terminated data packets from multiple 

20 sources, collectively referred to as Service Provides SP. Fig. 4 shows three 
typical service providers: an Internet Service Provider ISP for providing access 
to the Internet; a Company Network Server CSN for providing access to closed 
areas of the Internet, commonly called intranets and extranets; and Content 
Providers CP for providing access to various entertainment and news services, 

25 such as video-on-demand, etc. 

The GGSN comprises a scheduler/translator ST. As its name 
implies, it schedules transmission of packets on the basis of network load, 
packet priority, arrival time, etc. The scheduling part of the ST is largely known 
to the skilled reader. 

30 The translating part of the ST makes use of the filter Fl according to 

the invention. It maps data packets from the IP networks (11 - 12 in Fig. 1) to 
the packet radio network (13 in Fig. 1). The invention provides a solution for a 
situation wherein several applications and data flows share a common IP 
address but require different QoS values. 
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Fig. 5 illustrates the use of the filter Fl according to the invention at 
the GGSN. In step 71 the GGSN receives a data packet addressed to a given 
mobile station MS. The GGSN reads the MS's IP address from the 
corresponding protocol header and uses the filter Fl to determine the 
5 corresponding PDP context or QoS profile. The MS's IMSI can be determined 
from the packets' destination IP address. In step 72 the GGSN gets the 
corresponding Tunnel Identifier TID. Next, in step 73 the GGSN sends the 
data packet via the SGSN to the MS via that particular context which is 
associated with an appropriate QoS for this packet. 

10 Fig. 6 shows how a mobile station can configure the QoS mapping 

and interworking actions by means of a context activation procedure according 
to the invention. In step 6-1, the MS sends to the SGSN an Activate PDP 
Context Request comprising an NSAPI, a PDP type, a PDP address, an 
Access Point Name, QoS Requested, a Filter Specification and PDP 

15 configuration options. (For understanding the present information, the 
important parameters are the Filter and QoS information.) The MS may use 
the PDP Address to indicate whether it requires the use of a static or a 
dynamic PDP address. In the latter case, the MS shall leave PDP Address 
empty. The MS may use the Access Point Name to select a reference point to 

20 a certain external network. The Access Point Name is a logical name referring 
to the external packet data network that the subscriber wishes to connect to. 
QoS Requested indicates the desired QoS profile. The Filter specification 
indicates which external data packets are associated with a particular PDP 
context. Packets indicated by the filtering conditions of this filter should be 

25 considered as belonging to this particular PDP context. PDP Configuration 
Options may be used to request optional PDP parameters from the GGSN 
(see GSM 09.60). PDP Configuration Options is sent transparently through the 
SGSN. 

Using dynamic configuration and dynamic PDP addresses involves 
30 the problem of how to ensure that the context activation affects the correct 
GGSN, and how the GGSN knows whether to activate a new context with the 
same IP address or a different address. Three solutions for this problem can 
be found: 

1. Using an Access Point Name which points to a certain GGSN 
35 box and indicates that another context is needed, and using the same IP 
address. 
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2. Adding an indication (e.g. a new information element) to the 
context activation request, indicating to the GGSN (and the SGSN) that 
another context is needed. This context has the same IP address as the 
previous one. In this case the SGSN selects the same GGSN as for the 

5 previous context of that PDP type. 

3. Adding the PDP and IP addresses desired for the context to the 
context activation request message. This PDP/IP address may be given to one 
of the previous contexts, i.e. a dynamic address. In this case the SGSN 
selects the GGSN which is handling that particular address. 

10 Security functions may be performed in step 6-2, but they are not 

relevant for understanding the invention. 

In step 6-3, the SGSN validates the request 6-1 . The SGSN creates 
a Tunnel Identifier TID for the requested PDP context by combining the IMSI 
stored in the MM context with the NSAPI received from the MS. The SGSN 

15 may restrict the requested QoS attributes given its capabilities, the current 
load, and the subscribed QoS profile. Next, in step 6-3 the SGSN sends a 
Create PDP Context Request (comprising a PDP type, a PDP address, an 
Access Point Name, the negotiated QoS Profiles, the desired filter, the TID, 
and PDP configuration options) to the GGSN. The GGSN may also restrict the 

20 requested QoS attributes given its capabilities, and the current load. If the MS 
requests a dynamic address, then the SGSN lets a GGSN allocate the 
dynamic address. The SGSN may restrict the requested QoS attributes given 
its capabilities, the current load, and the subscribed QoS profile. The SGSN 
sends a Create PDP Context Request (PDP Type, PDP Address, Access 

25 Point Name, QoS Negotiated, Filter spec, TID, Selection Mode, PDP 
Configuration Options) message to the affected GGSN. Access Point Name 
shall be the APN Network Identifier of the APN selected according to the 
procedure described in annex A. PDP Address shall be empty if a dynamic 
address is requested. The GGSN may use the Access Point Name to find an 

30 external network. Selection Mode indicates whether a subscribed APN was 
selected, or whether a non-subscribed APN sent by MS or a non-subscribed 
APN chosen by SGSN was selected. Selection Mode is set according to 
annex A. The GGSN may use Selection Mode when deciding whether to 
accept or reject the PDP context activation. For example, if an APN requires 

35 subscription, then the GGSN is configured to accept only the PDP context 
activation that requests a subscribed APN as indicated by the SGSN with 
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Selection Mode. The GGSN creates a new entry in its PDP context table and 
generates a Charging Id. The new entry allows the GGSN to route PDP PDUs 
between the SGSN and the external PDP network, and to start charging. The 
GGSN may further restrict QoS Negotiated given its capabilities and the 
5 current load. GGSN shall maintain information for QoS mapping and multiplex 
incoming data packets from the external network onto the active PDP contexts 
according to the defined filtering conditions at the GGSN. For the outgoing 
packets, a certain external QoS might be associated with the packets of a 
particular PDP context. The GGSN then returns a Create PDP Context 

10 Response (TID, PDP Address, BB Protocol, Reordering Required, PDP 
Configuration Options, QoS Negotiated, Charging Id, Cause) message to the 
SGSN. PDP Address is included if the GGSN allocated a PDP address. BB 
Protocol indicates whether TCP or UDP shall be used to transport user data 
on the backbone network between the SGSN and GGSN. Reordering 

15 Required indicates whether the SGSN shall reorder N-PDUs before delivering 
the N-PDUs to the MS. PDP Configuration Options contain optional PDP 
parameters that the GGSN may transfer to the MS. These optional PDP 
parameters may be requested by the MS in the Activate PDP Context Request 
message, or may be sent unsolicited by the GGSN. PDP Configuration 

20 Options is sent transparently through the SGSN. The Create PDP Context 
messages are sent over the GPRS backbone network. If the QoS Negotiated 
received from the SGSN is incompatible with the PDP context being activated 
(e.g., the reliability class is insufficient to support the PDP type), then the 
GGSN rejects the Create PDP Context Request message. The compatible 

25 QoS profiles can be configured by the GGSN operator. 

In step 6-4, the GGSN returns a Create PDP Context Response 
(comprising a TID, a PDP Address, the negotiated QoS Profiles, and PDP 
configuration options) to the SGSN. The SGSN inserts the NSAPI with the 
GGSN address in the PDP context. If the MS has requested a dynamic 

30 address, the PDP address received from the GGSN is inserted in the PDP 
context. The SGSN selects a Radio Priority based on QoS Negotiated, and 
returns an Activate PDP Context Accept (PDP Type, PDP Address, Tl, QoS 
Negotiated, Radio Priority, PDP Configuration Options) message to the MS. 
The SGSN is now able to route PDP PDUs between the GGSN and the MS, 

35 and to start charging. 
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Next, in step 6-5, the SGSN selects a Radio Priority Level based on 
each negotiated QoS profile, and returns an Activate PDP Context Accept 
(comprising a PDP type, a PDP Address, an NSAPI, the negotiated QoS 
Profiles, a Radio Priority Level and a SAPI for each QoS profile, the filter and 
5 PDP configuration options) to the MS. Now the SGSN is able to route PDP 
PDUs between the GGSN and the MS. The SAPI indicates which QoS profile 
uses which SAPI. Fig. 7 shows a context modification procedure. In step 7-1 
the MS sends the SGSN an Modify PDP Context Request. In step 7-3 the 
SGSN sends to the GGSN an Update PDP Context Request. Both of these 

10 requests comprise the filter with modified parameters. The filter indicates 
which external data packets are associated with a particular PDP context. 
Packets indicated by the filtering conditions should be interpreted as belonging 
to this particular PDP context and they should be provided with the QoS 
negotiated for the context. The Update PDP Context Request message is 

15 used to add, modify or cancel a QoS profile of a PDP context. If the GGSN 
receives from the SGSN a negotiated QoS which is incompatible with the PDP 
context being modified (e.g. the reliability class in insufficient to support the 
PDP type), the GGSN rejects the request. Compatible QoS profiles are 
configured by the GGSN operator. The GGSN may again restrict the 

20 requested QoS attributes given its capabilities, and the current load. The 
GGSN stores the negotiated QoS values. The GGSN shall revise the QoS 
mapping information to conform to the new filter spec and Qos Profile 
negotiated (included in the request message). In steps 7-4 and 7-5 a positive 
response is returned to the MS. 

25 The messages 7-1 through 7-5 are known from GPRS phase 2. 

According to the invention, the messages 7-1 and 7-3 are modified to convey 
the desired filtering parameters (and the messages 7-4 and 7-5 are modified 
to return a suitable acknowledgement). 

According to yet another embodiment of the invention, the filter 

30 function in a first direction (e.g. downlink) can be modified using information 
included in the packets sent in the second direction (e.g. uplink). This 
embodiment requires no extra signalling. According to this exemplary 
embodiment the following traffic classes are defined (RT = Real-Time, NRT = 
Non-Real-Time): 
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Conversational and Streaming classes are real-time oriented traffic 
classes for which resources are reserved. Interactive and Background classes 
are best effort classes, which do not have reserved resources. For these 
classes, GPRS style resource allocation can be used, i.e. the MS sends radio 
5 resource requests on demand. 

For the real time classes, i.e. the Conversational and Streaming 
classes, method presented above is very efficient, i.e. carrying the filter 
information in PDP context operations to the GGSN so that GGSN can map 
incoming IP packets to the correct QoS class. However, with Interactive and 

10 Background classes this involves large amounts of signalling, which in some 
situations might be unacceptable. An example of such a situation is a query 
sent to a Domain Name Server DNS (not shown), in which case the net flow 
might consist of only two packets. 

In this example, Interactive class is selected as the default QoS 

15 class. This means that if there is no information about the QoS requirement of 
an incoming flow, or the flow information does not conform to any of the filter 
conditions, the Interactive class will be selected. In addition, flows belonging to 
the background class can be identified by the GGSN "on the fly". This means 
that when the GGSN gets a packet from the MS in the Background class, it 

20 shall take notice of the flow identification information, and modify the filter 
characteristics associated with the background class, for mapping the 
downlink flow corresponding to the flow in question to the Background class. 
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When a packet comes in the downlink direction, the GGSN checks the flow 
identification information associated with the Background class. If the flow filter 
information associated with the Background class matches the header 
information of the received IP packet, then the packet is directed to the 
5 Background class. 

Flow information related to the Background class can be handled as 
follows. The MS has knowledge about flows that should be carried using 
Background class. The user can configure this mapping of flows to the 
Background class. For example, the user can configure file transfers to use 

10 Background class by using a suitable configuration application. Alternatively, 
the information can be obtained e.g. from some external QoS information (e.g: 
Internet QoS information). In other words, the MS has filter criteria for flows to 
be mapped to the Background class. An essential feature of this embodiment 
is that the MS has knowledge on which flows should be directed to the 

15 Background class, and it sends these packets to the corresponding link. When 
the GGSN gets packets from the MS, it knows the QoS class the packets are 
associated with. When the GGSN gets a packet from the Background class it 
checks whether it already has an entry for that flow in a list (not shown) which 
contains flow information of all flows belonging to the Background class. If 

20 there is no entry for that flow in the list, the GGSN modifies the filter used 
when mapping the downlink flows to the Background class so that the 
downlink flow corresponding to the uplink flow the received packet belongs to 
will be mapped to the Background class. This can be done by including the 
flow identification information of the uplink packet to the flow information list 

25 from which the downlink packets are mapped to the Background class. So, 
flows belonging to the background class are identified in the GGSN "on the 
fly". 

When the GGSN gets a packet from the Internet or from any other 
external network, it checks the filter information associated with 
30 Conversational, Streaming and Background classes. If the GGSN finds that 
the characteristics of the packet conform to the relevant filter conditions, it 
forwards the packet to the corresponding QoS class. If there is no entry for 
that particular flow, then the packet is forwarded to the Interactive class, which 
is the default class. 

35 This embodiment dramatically decreases the need for signalling 

because the Interactive class will be the most frequently used QoS class. 
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There are many cases in which IP packets do not actually form a flow, but 
there are instead only one or a few IP packets going uplink and a few packets 
coming downlink as a response. A DNS query is a good example of this kind 
of behaviour. Signalling PDP context modification in these cases would cause 

5 a relatively high amount of signalling which can be avoided using this 
embodiment. Instead, only the initial PDP context activation is needed to get 
an IP address for the MS. 

The description only illustrates preferred embodiments of the 
invention. The invention is not, however, limited to these examples but it may 

10 vary within the scope of the appended claims. For example, it is not necessary 
that the receiving terminal is a mobile station but it can be any network 
element. Similarly, it is not necessary that the MT data packets originate from 
the IP network. Instead, the invention is applicable e.g. in a MS to MS call via 
a GGSN node. In this case the leg from one MS to the GGSN is a first 

15 communication subsystem and the leg from the GGSN to the other MS is a 
second communication subsystem. 
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Claims 

1. A method for sending data packets (DP) from a first 
communication subsystem (11, 12), via a first network element (GGSN) to a 
second network element (MS) in a second communication subsystem (13); 
5 the method comprising the steps of: 

sending the data packets (DP) in a first plurality of data flows in said 
first communication subsystem (11, 12); 

mapping said first plurality of data flows to a second plurality of data 
flows in said second communications subsystem (13); 
10 characterized by: 

establishing at least one filter (Fl) for controlling said mapping; 

associating said at least one filter (Fl) with a data flow within said 

second plurality; and 

mapping at least one data flow on the basis of said filter (Fl). 

15 2. A method according to claim 1, characterized in that the 

first communications subsystem is an IP network and the method comprises 
allocating one IP address which is shared by all data flows within said second 
plurality. 

3. A method according to claim 1, characterized in that the 
20 first communications subsystem is an IP network and the method comprises 

allocating a separate IP address for each data flow within said second 
plurality. 

4. A method according to any one of the preceding claims, 
characterized by configuring said filter (Fl) from said second network 

25 element (MS). 

5. A method according to any one of the preceding claims, 
characterized in that said first communications subsystem is a packet 
radio network employing PDP protocol and said configuring step comprises 
sending a PDP context activation message (6-1, 6-3) or a PDP context 

30 modification message (7-1 , 7-3). 

6. A method according to any one of the preceding claims, 
characterized in that said associating is based on the second network 
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element's (MS) address, preferably its IP address, in said first communication 
subsystem (11,12). 

7. A method according to any one of the preceding claims, 
characterized in that said associating is based on the second network 
element's (MS) identifier, preferably its IMSI or Tunnel Identifier, in said 
second communication subsystem (13). 

8. A method according to any one of the preceding claims, 
characterized by: 

performing said mapping on the basis of said filter (Fl) to data flows 
conveying real-time information; and 

establishing default parameters for mapping the remaining data 

flows. 

9. A method according to any one of the preceding claims, 
characterized by defining one data flow within the second plurality as a 
default data flow, to which are mapped all data flows of the first plurality which 
do not conform to the at least one filter (Fl). 

10. A method according to any of the preceding claims, 
characterized in that at least one of the data flows is bidirectional 
having a first direction from the first plurality to the second plurality and a 
second direction which is inverse to the first direction, and the at least one 
filter (Fl) is modified on the basis of user data packets sent in the second 
direction. 

11. A method according to claim 10, c h a r a c t e r i z e d in that a 
gateway element (GGSN) mapping the data flows: 

receives a data packet (DP) in the second direction from a first data 
flow within the second plurality; 

forwards the data packet to a second data flow within the first 

plurality; and 

modifies the at least one filter (Fl) for mapping the second data flow 
to the first data flow. 

12. A method according to any of the preceding claims, 
characterized in that at least one data flows within the first plurality is 
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tunnelled over a data flow within the second plurality, and at least two data 
flows within the second plurality have mutually different Quality of Service 
characteristics. 

13. A first network element, preferably a Gateway GPRS Support 
5 Node (GGSN), for routing data packets (DP) from a first communication 

subsystem (11, 12), to a second network element (MS) in a second 
communication subsystem (13); 

said first network element (GGSN) being adapted to: 

receive the data packets (DP) from said first communication 
1 0 subsystem (1 1 , 1 2) in a first plurality of data flows; 

map said first plurality of data flows to a second plurality of data 
flows in said second communication subsystem (13); 

characterized in that said first network element (GGSN) is 
adapted to: 

15 establish at least one filter (Fl) for controlling said mapping; 

associate said at least one filter (Fl) with a data flow within said 
second plurality; and 

map at least one data flow on the basis of said filter (Fl). 

14. A digital signal for creating (6-1, 6-3) or modifying (7-1, 7-3) a 
20 PDP context in a support node (GGSN) for interfacing a first communication 

subsystem (11, 12) with a second communication subsystem (13); 
characterized in that said signal comprises information which at least 
partially defines a filter (Fl) for controlling mapping of data flows from said first 
communication subsystem to said second communication subsystem (13) by 
25 said support node (GGSN). 
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(57) Abstract 

A method and a GGSN support node for sending data 
packets to a mobile station (MS) in a mobile 
communications system (13) from an external 
communication system (11, 12). The GGSN receives data 
packets from the external communication system (11, 12) 
in a first plurality of data flows which it maps to a second 
plurality of data flows in the mobile communications 
system (13). It establishes at least one filter (Fl) for 
controlling the mapping and associates the filter (Fl) with 
the mobile station. It also maps at least one of the data 
flows on the basis of the filter (Fl) and configures the filter 
(Fl) on the basis of information (6-1, 7-1) which preferably 
originates from the mobile station (MS). 
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